Consumers are increasingly using kiosks to conduct business with enterprises. The kiosks come in a variety of sizes and are used for a variety of purposes. Some kiosks are drive through, such as fast food establishments, pharmacies, banks, and the like. Other kiosks are stationary located in gas stations, airlines, grocery stores, department stores, and the like.
In addition, what is considered a kiosk is evolving with today's technology. For example, digital signs now provide advertisements and mechanisms for users to interact with the displays to perform transactions. Such mechanisms include blue tooth communication, Near Field Communication (NFC), Quick Response (QR) code scanning, Wi-Fi communication, and the like.
Even websites and stores online may be viewed as a form of a kiosk. A tremendous amount of services are now available online via website portals. Businesses even attempt to tie their backend systems to existing website services offered by third parties.
By and Large, Large scale Self Service Device (SSD) systems (and websites/applications) must communicate with a heterogeneous mixture of reservation and service providers via numerous disparate and independent interfaces. Many of these interfaces provide similar functionality but must be used in conjunction with custom business rules to provide a complete solution. These interfaces, in combination with custom software, generally use a combination of web services, file transfers, databases, messages, or screen-scraping processes as ad-hoc gateways to communicate with vendor systems.
Self-service software applications are applications designed to allow the end user to perform relatively complex tasks normally requiring expert knowledge through a simplified interface that abstracts away the requirement for such expertise. (E.g., a traveler using an airline check-in kiosk does not need to know the correct sequence of host system commands to execute in order to successfully check in for their flight.)
In order for such systems to operate, they must automate much of the expertise normally provided by an expert human user. To do so, many applications rely upon some form of a centralized processing engine supporting 1) validation, 2) business rules, and 3) service orchestration. Once implemented, such applications typically handle user sessions by gathering information from the user and external services, merging and transforming the information based on business rules, and presenting the user with simplified information and further options. Collectively, from the time when the user first begins using the application until the time that they complete their interaction, the sequence of steps executed is referred to as a session flow. Due to the highly specific interactions required by individual applications and the organizations, encoding session flow into self-service applications requires supporting enormous programming variability.
To date, many solutions that have targeted similar problems have been built upon tremendously expensive Business Process Management (BPM) and Business Process Execution Language (BPEL) platforms. The major weakness of these approaches is that they are too large, complex, and unwieldy to work for smaller scale self-service applications. Moreover, such systems are not typically designed with the low latency required to support near real time user interaction. Instead, most real-world implementations of self-service applications have constructed ad-hoc solutions that border on the edge of unmanageable complexity. Combined with the variability discussed above, such solutions have traditionally suffered from extremely high maintenance and customization costs.